web_interface/templates/v3/partials/tools.html (1)

715-719: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Diagnostics polling isn't cleared when the user navigates away from the Tools tab.

window._diagPollInterval is only cleared/reset when this partial is re-swapped in; if the user switches to a different tab entirely, the interval keeps firing fetch('/api/v3/system/status') every 10s in the background (the if (!panel) return; guard in loadSystemDiagnostics prevents a JS error, but the network/server call still happens). On a resource-constrained Raspberry Pi, this is unnecessary CPU/network churn while the panel isn't even visible.

Consider clearing the interval on an HTMX "leaving this view" hook (e.g. htmx:beforeSwap on the outer container, or a MutationObserver/unload handler scoped to #tools-root) rather than only on re-entry.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@web_interface/templates/v3/partials/tools.html` around lines 715 - 719, The
diagnostics polling interval is only stopped when the Tools partial is reloaded,
so it keeps running after the user leaves the tab. Update the polling setup
around window._diagPollInterval and loadSystemDiagnostics to also clear the
interval when the Tools view is being removed or swapped out, using an HTMX
view-leave hook on the outer container (for example htmx:beforeSwap) or an
equivalent scoped teardown tied to `#tools-root`.

src/wifi_manager.py (1)

1923-1972: 🚀 Performance & Scalability | 🔵 Trivial

Enable path can block the Flask worker for several seconds.

set_wifi_radio(True, ...) delegates to _ensure_wifi_radio_enabled(), whose retry loop can sleep for a total of ~10-20s across attempts (2s + 1s per retry, up to 3 retries, plus rfkill checks). Since this runs synchronously inside the /api/v3/wifi/radio POST request handler, a slow/failing radio-enable ties up the request thread for that duration. This mirrors the existing pattern in enable_ap_mode/disable_ap_mode (also synchronous), so it's not new to this PR, but worth flagging since a new UI surface now exercises it directly from a "quick toggle" control that users will expect to be near-instant.

Consider offloading long-running WiFi radio changes to a background thread with the endpoint returning immediately (with the UI polling for the new state), or documenting the expected multi-second latency in the toggle's UI copy.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/wifi_manager.py` around lines 1923 - 1972, The enable path in
set_wifi_radio(True, ...) can block the Flask request thread because it waits
inside _ensure_wifi_radio_enabled() with retries and sleeps. Update the
/api/v3/wifi/radio flow so the radio change is handled asynchronously in a
background worker/thread and the endpoint returns immediately, or add
UI/documentation copy that clearly sets expectations for the multi-second delay.
Use the existing set_wifi_radio and _ensure_wifi_radio_enabled symbols to keep
the fix aligned with the current enable/disable handling.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/wifi_manager.py (1)

1970-1974: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Add stack trace to the fallback error log and narrow the catch.

The trailing except Exception swallows all remaining error types and logs without a stack trace, which hampers remote debugging on the Pi. subprocess.run here realistically raises OSError/SubprocessError, so catching those (plus keeping a defensive fallback with exc_info=True) preserves context.

As per coding guidelines: "Catch specific exception types ... rather than generic exceptions" and "Include stack traces in error logs to provide complete error context for debugging".

♻️ Proposed change

-        except subprocess.TimeoutExpired:
-            return False, "Command timed out while disabling WiFi radio.", 'timeout'
-        except Exception as e:
-            logger.error("Error disabling WiFi radio: %s", e)
-            return False, "An error occurred while disabling WiFi radio.", 'error'
+        except subprocess.TimeoutExpired:
+            return False, "Command timed out while disabling WiFi radio.", 'timeout'
+        except (OSError, subprocess.SubprocessError) as e:
+            logger.error("Error disabling WiFi radio: %s", e, exc_info=True)
+            return False, "An error occurred while disabling WiFi radio.", 'error'

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/wifi_manager.py` around lines 1970 - 1974, The fallback error handling in
the WiFi radio disable path is too broad and loses traceback context. In the
code around the `subprocess.run` call and its surrounding `except` blocks,
replace the generic `except Exception` with narrower handling for the expected
`OSError`/`subprocess.SubprocessError` cases, and keep a defensive fallback that
logs with stack trace details. Update the `logger.error` call in this branch to
include exception info so remote debugging has the full context.

Sources: Coding guidelines, Linters/SAST tools